home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Collection of Internet
/
Collection of Internet.iso
/
protocol
/
standard
/
ccitt
/
1992
/
x
/
x402_6.asc
< prev
next >
Wrap
Text File
|
1993-07-14
|
12KB
|
203 lines
Section Six - OSI Realization
25. Overview
This section describes how the MHS is realized by means of OSI.
This section covers the following topics:
a) Application service elements
b) Application contexts
26. Application Service Elements
This clause identifies the application service elements (.I.ab:ASEs;) that
figure in the OSI realization of Message Handling.
In OSI the communication capabilities of open systems are organized into groups
of related capabilities called ASEs. The present clause reviews this concept from
the OSI Reference Model, draws a distinction between symmetric and asymmetric
ASEs, and introduces the ASEs defined for or supportive of Message Handling.
Note Besides the ASEs discussed, the MHS relies upon the Directory Access
Service Element defined in Recommendation X.519. However, since that ASE does not
figure in the ACs for Message Handling (see Recommendation X.419), it is not discussed
here.
26.1 The ASE Concept
The ASE concept is illustrated in Figure 12/X.402, which depicts two
communicating open systems. Only the OSI-related portions of the open systems, called AEs, are
shown. Each AE comprises a UE and one or more ASEs. A UE represents the
controlling or organizing portion of an AE which defines the open system's role (e.g., that
of an MTA). An ASE represents one of the communication capability sets, or
services (e.g., for message submission or transfer), that the UE requires to play its
role.
The relationship between two AEs in different open systems is called an
application association. The ASEs in each open system communicate with their peer ASEs in
the other open system via a presentation connection between them. That
communication is what creates and sustains the relationship embodied in the application
association. For several ASEs to be successfully combined in a single AE, they must be
designed to coordinate their use of the application association.
+----+ | 01 | | 02 | | 03 | | 04 | | 05 | | 06 | | 07 | | 08 | | 09 | | 10 | | 11
| | 12 | | 13 | | 14 | | 15 | | 16 | | 17 | | 18 | | 19 | | 20 | | 21 | | 22 | |
23 | | 24 | | 25 | | 26 | | 27 | | 28 | | 29 | +----+
Figure .F.:12/X.402 The ASE Concept
An ASE plays the largely mechanical role of translating requests and responses
made by its UE to and from the form dictated by the application protocol that
governs the ASE's interaction with its peer ASE in the open system to which the
association connects it. The ASE realizes an abstract service, or a part thereof, for
purposes of OSI communication (see Recommendation X.407).
Note Strictly speaking, an open system's role is determined by the behavior of
its application processes. In the Message Handling context an application process
realizes a functional object of one of the types defined in clause 7. A UE in turn
is one part of an application process.
26.2 Symmetric and Asymmetric ASEs
The following two kinds of ASE, illustrated in Figure 13/X.402, can be
distinguished:
a) .I.gl:symmetric;: Said of an ASE by means of which a UE both supplies and
consumes a service. The ASE for message transfer, e.g., is symmetric because both
open systems, each of which embodies an MTA, offer and may consume the service of
message transfer by means of it.
b) .I.gl:asymmetric;: Said of an ASE by means of which a UE supplies or consumes
a service, but not both, depending upon how the ASE is configured. The ASE for
message delivery, e.g., is asymmetric because only the open system embodying an MTA
offers the associated service and only the other open system, which embodies a UA
or MS, consumes it.
+----+ | 01 | | 02 | | 03 | | 04 | | 05 | | 06 | | 07 | | 08 | | 09 | | 10 | | 11
| | 12 | | 13 | | 14 | | 15 | | 16 | | 17 | | 18 | | 19 | | 20 | | 21 | | 22 | |
23 | | 24 | | 25 | | 26 | | 27 | | 28 | | 29 | +----+
Figure .F.:13/X.402 Symmetric and Asymmetric ASEs
With respect to a particular asymmetric ASE, one UE supplies a service which the
other consumes. The ASEs co-located with the UEs assist in the service's supply
and consumption. The resulting four roles are captured in Figure 14/X.402 and in the
following terminology:
a) x-.I.gl:supplying UE;: An application process that supplies the service
represented by asymmetric ASE x.
b) x-.I.gl:supplying ASE;: An asymmetric ASE x configured for co-location with
an x-supplying-UE.
c) x-.I.gl:consuming UE;: An application process that consumes the service
represented by asymmetric ASE x.
d) x-.I.gl:consuming ASE;: An asymmetric ASE x configured for co-location with
an x-consuming-UE.
+----+ | 01 | | 02 | | 03 | | 04 | | 05 | | 06 | | 07 | | 08 | | 09 | | 10 | | 11
| | 12 | | 13 | | 14 | | 15 | | 16 | | 17 | | 18 | | 19 | | 20 | | 21 | | 22 | |
23 | | 24 | | 25 | | 26 | | 27 | | 28 | | 29 | +----+
Figure .F.:14/X.402 Terminology for Asymmetric ASEs
As indicated, the four roles described above are defined relative to a particular
ASE. When an AE comprises several asymmetric ASEs, these roles are assigned
independently for each ASE. Thus, as shown in Figure 15/X.402, a single UE might serve
as the consumer with respect to one ASE and as the supplier with respect to
another.
+----+ | 01 | | 02 | | 03 | | 04 | | 05 | | 06 | | 07 | | 08 | | 09 | | 10 | | 11
| | 12 | | 13 | | 14 | | 15 | | 16 | | 17 | | 18 | | 19 | | 20 | | 21 | | 22 | |
23 | | 24 | | 25 | | 26 | | 27 | | 28 | | 29 | +----+
Figure .F.:15/X.402 Multiple Asymmetric ASEs
26.3 Message Handling ASEs
The ASEs that provide the various Message Handling services are listed in the
first column of Table 11/X.402. For each ASE listed, the second column indicates
whether it is symmetric or asymmetric. The third column identifies the functional
objects--UAs, MSs, MTAs, and AUs--that are associated with the ASE, either as consumer
or as supplier.
Table .T.:11/X.402 Message Handling ASEs
+------+------+--------------------+ | | | Functional Objects | |
| +--------------------+ | ASE | Form | UA MS MTA AU | +------+------+--------------------+ | MTSE | SY | - - CS - | +------+------+---------
------------+ | MSSE | ASY | C CS S - | | MDSE | ASY | C C S
- | | MRSE | ASY | C S - - | | MASE | ASY | C CS S - | +--
-----+------+--------------------+ +- Legend -------------------+ | SY symmetric
C consumer | | ASY asymmetric S supplier | +----------------------------+
The Message Handling ASEs, summarized in the table, are individually introduced
in the clauses below. Each is defined in Recommendation X.419.
26.3.1 Message Transfer
The Message Transfer Service Element (.I.ab:MTSE;) is the means by which the
transfer transmittal step is effected.
26.3.2 Message Submission
The Message Submission Service Element (.I.ab:MSSE;) is the means by which the
submission transmittal step is effected.
26.3.3 Message Delivery
The Message Delivery Service Element (.I.ab:MDSE;) is the means by which the
delivery transmittal step is effected.
26.3.4 Message Retrieval
The Message Retrieval Service Element (.I.ab:MRSE;) is the means by which the
retrieval transmittal step is effected.
26.3.5 Message Administration
The Message Administration Service Element (.I.ab:MASE;) is the means by which a
UA, MS, or MTA places on file with one another information that enables and
controls their subsequent interaction by means of the MSSE, MDSE, MRSE, and MASE.
26.4 Supporting ASEs
The general-purpose ASEs upon which Message Handling ASEs depend are listed in
the first column of Table 12/X.402. For each listed ASE, the second column indicates
whether it is symmetric or asymmetric.
Table .T.:12/X.402 Supporting ASEs
+------+------+ | ASE | Form | +------+------+ | ROSE | SY | | RTSE | SY | |
ACSE | SY | +------+------+ +- Legend -------+ | SY symmetric | | ASY
asymmetric | +----------------+
The supporting ASEs, summarized in the table, are individually introduced in the
clauses below.
26.4.1 Remote Operations
The Remote Operations Service Element (.I.ab:ROSE;) is the means by which the
asymmetric Message Handling ASEs structure their request-response interactions
between consuming and supplying open systems.
The ROSE is defined in Recommendation X.219.
26.4.2 Reliable Transfer
The Reliable Transfer Service Element (.I.ab:RTSE;) is the means by which various
symmetri and asymmetric Message Handling ASEs convey information objects--
-especially large ones (e.g., facsimile messages)--between open systems so as to
ensure their safe-storage at their destinations.
The RTSE is defined in Recommendation X.218.
26.4.3 Association Control
The Association Control Service Element (.I.ab:ACSE;) is the means by which all
application associations between open systems are established, released, and in
other respects managed.
The ACSE is defined in Recommendation X.217.
27. Application Contexts
In OSI the communication capabilities (i.e., ASEs) of two open systems are
marshalled for a particular purpose by means of application contexts (.I.ab:ACs;). An AC
is a detailed specification of the use of an association between two open systems,
i.e., a protocol.
An AC specifies how the association is to be established (e.g., what
initialization parameters are to be exchanged), what ASEs are to engage in peer-to-peer
communication over the association, what constraints (if any) are to be imposed upon
their individual use of the association, whether the initiator or responder is the
consumer of each asymmetric ASE, and how the association is to be released (e.g.,
what finalization parameters are to be exchanged).
Every AC is named (by an ASN.1 Object Identifier). The initiator of an
association indicates to the responder the AC that will govern the association's use by
conveying the AC's name to it by means of the ACSE.
An AC also identifies by name (an ASN.1 Object Identifier) the abstract syntaxes
of the APDUs that an association may carry as a result of its use by the AC's
ASEs. Conventionally one assigns a name to the set of APDUs associated either with
each individual ASE or with the AC as a whole. The initiator of an association
indicates to the responder the one or more abstract syntaxes associated with the AC by
conveying their names to it via the ACSE.
The abstract syntax of an APDU is its structure as an information object (e.g.,
an ASN.1 Set comprising an Integer command code and an IA5 String command
argument). It is distinguished from the APDU's transfer syntax which is how the information
object is represented for transmission between two open systems (e.g., one octet
denoting an ASN.1 Set, followed by one octet giving the length of the Set, etc.).
The ACs by means of which the various Message Handling services are provided are
specified in Recommendation X.419. These protocols are known as .I.ab:P1;,
.I.ab:P3;, and .I.ab:P7;.
Note The nature of a message's content does not enter into the definition of
Message Handling ACs because the content is encapsulated (as an Octet String) in the
protocols by means of which it is conveyed.